home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4429 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Allocation of memory
  5. Date: 4 Feb 1996 07:56:24 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4f2kv8INNlql@keats.ugrad.cs.ubc.ca>
  8. References: <4evre9$8r4@news.rz.uni-passau.de>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10. Keywords: realloc
  11.  
  12. In article <4evre9$8r4@news.rz.uni-passau.de>,
  13. Klaus Berndl <berndl@piligrim.uni-passau.de> wrote:
  14. >2) With ALLOCSIZE set to 100000000 the program works correct. But if i set
  15. >   ALLOCSIZE to 300000000, i reach the following output:
  16. >
  17. >     Klaus
  18. >
  19. >      t-realloc failed
  20. >
  21. >     test1
  22. >     Bus Error (core dumped)
  23. >
  24. >   What is 'realloc' doing exactly? Normally if realloc can`t allocate the
  25. >   requested memory it returns NULL and doesn`t allocate memory. Why the 
  26. >   second realloc-call (x = ...) fails? There must be 1000000 Byte memory
  27. >   because of the first try with ALLOCSIZE 100000000 works!
  28.  
  29. This is not clear. At first you say that the program works correctly with
  30. ALLOCSIZE set to 10^8. This contradicts your assertion that the second
  31. realloc() call fails.
  32.  
  33. By the way, how is it guaranteed that an allocation of 10^6 bytes will succeed
  34. just because a previous allocation of 10^8 bytes succeeded? This is a fallacy,
  35. since if I took it as an inductive hypothesis, I would come to the conclusion
  36. that I can allocate any amount of memory I want. (I can allocate one byte.
  37. Given that I have allocated n bytes, I surely can allocate an extra byte to get
  38. n + 1 bytes. Therefore I can allocate any number of bytes I want.)
  39.  
  40. All we know is that you can get 10^8 bytes, and that you cannot get 3 * 10^8
  41. bytes. Thus the actual amount you _can_ get is somewhere between these two
  42. limits in a 2 * 10^8 range. Assuming that the actual limit is randomly
  43. determined in this range, your probability of not being able to allocate
  44. another megabyte out of the 200 is about 1/200, so I could see where your
  45. surprise comes from. :) Of course, you don't know where the actual limit lies.
  46.  
  47. It could be that your program (under your typical working load conditions) is
  48. able to get 100MB, which gets you just within a megabyte of virtual memory
  49. exhaustion. Or it could be that the malloc() routines are simply broken.
  50.  
  51. Also, do you have limits set on process size? That could also bite you.
  52. -- 
  53.  
  54.